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An analysis of Vista vs. prior versions of Windows' implementation of cryptographic primitives to 
protect sensitive in-memory data, such as password hashes. Vista SP1 introduces significant 
changes to these mechanisms and will change the way analysts, researchers and attackers approach 
the acquisition of protected in-memory data. A basic overview of pre- and post-Vista security 
architecture is given to provide some groundwork for the detailed analysis. 
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Introduction 

Windows Vista introduces some significant changes in its security architecture; there are also some 
major changes between Vista RTM (release-to-manufacturing; a Microsoft term for "gold" code or 
SPO) and Vista SP1. This paper will first provide a brief overview of some of those architectural 
changes, and will then focus on the specific components that will be covered in greater detail in 
subsequent sections. The focus areas for this paper will be on logon and authentication, encryption 
and some networking enhancements in IPSec. 

Most of the discussion in this paper will focus on the Local Security Authority service - LSASRV.dl, 
the new Cryptography Next Generation (CNG) APIs - BCryptdll and NCrypt.dll, and some 
enhancements to IPSec contained in IKEEXT.dll. 



Overview of the Vista Security Architecture 

To lay some basic groundwork, let's first review some of the major changes in the security 
architecture of Windows Vista vs. prior Windows operating systems. 

Windows Vista has produced many changes that are security feature/function related and some 
that are low-level changes that help combat malicious software from executing. Things like 
Address Space Layout Randomization (ASLR], Data Execution Prevention (DEP), User Account 
Control (UAC) are all intended to make Vista a more secure system - these technologies have been 
adequately discussed elsewhere and we will not dive deeply into them here. 

There have also been some specific architectural changes to Vista that focus on the discrete security 
modules, functions, APIs and components that handle logons, encryption and networking. We will 
first discuss these changes at a high level and then dive into specific details in later sections. 
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Pre-Vista Security Architecture 

For comparison, we will first review some of the major components of the Windows security 
architecture pre-Vista. The diagram in Figure 1 illustrates the architecture for logon and 
authentication, which includes the following components: 

LSASS - Local Security Authority Subsystem 

o LSA interfaces with many other security related components, all of which are not 
listed here. For our purposes, LSASRV.dll is the most important component. 
WinLogon - The user-mode process that provides interactive logon services 
MsGina - The user interface for WinLogon 

Authentication Packages - Authentication packages validate a user's logon credentials. In 
Windows there are three primary packages: 

o MSV1_0 - authentication package for LM/NTLM authentication requests 

o Kerberos - for Windows Domains 

o SPNEGO - a package to select between Kerberos (preferred) or NTLM 
It is possible to create custom authentication packages that can be implemented as a DLL. 
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Figure 1 - Pre-Vista Security Architecture 
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Figure 2 provides details about the Windows Logon architecture. This is a big topic - a whole paper 
on just the Windows logon process could be (and has been) written; we will focus on the important 
concepts relevant to this paper. Session contained all services, including system services and the 
interactive logons of any users on the system. 
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Figure 2 - Pre-Vista Logon Architecture 



Also, unless it was replaced by a third-party, all interactive logon requests were processed by 
MSGina (msgina.dll), which provides the GUI to capture user's input to pass to WinLogon, which 
would then pass on to LSASS and the appropriate Authentication Package. 
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Vista Security Architecture 

The Vista security architecture has departed from two major components that were discussed 
previously - namely MSGina and the implementation of Session 0. We will also illustrate some 
modifications in how Vista implements the Windows Integrity Mechanism/Levels to provide 
separation of privileges and processes. Lastly, there is the upgrade to the Crypto API - which is 
called the Cryptography Next Generation (CNG) API. It is important to understand these changes 
since they will be a large part of the remainder of this paper. 

Logon Architecture 

Vista has a redesigned architecture for processing both interactive (i.e. logging in from the 
keyboard) and other logons, such as service and network logons. Session now contains only 
System Services and does not process interactive logons. I have found one discrepancy to this, 

however, in the vmware user user account (shown below in Figure 3). This account will 

show up as an interactive logon in Session on Vista (I have not yet researched the details of this). 
All other true interactive logons seem to receive sequential logon sessions, i.e. Session 1, Session 2, 
etc. Other specific details of the new logon architecture are listed below and illustrated in Figure 4. 



Figure 3 - Interactive Logon in Session 



Vista Logon Architecture changes: 



Removal of MsGina - it is probably more accurate to say that any Gina dll - whether it be 

Microsoft's or a third party, will not be utilized by WinLogon. 

WinLogon and Logon Sessions vs. SessionO - Separation of logon sessions for users and 

services. Concept is that services should have no need to interact with the desktop 

LogonUI (new) and Credential Providers (new) components - essentially the replacement for 

Gina. Credential Providers architecture is meant to be extensible and allow for multiple plug-in 

providers. WinLogon handles interactive logons directly. LogonUI is COM based 
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Figure 4 - Vista Logon Architecture 



Integrity Mechanism 

Another important component and enhancement of the Vista security architecture is the Integrity 
Mechanism. Although the Integrity Mechanism and Levels are not new in Vista, there are some 
changes in Vista vs. prior operating systems that are important for our purposes. Integrity Levels 
are one way that Windows enforces Mandatory Access Controls to specific system objects and 
resources. It also provides some level of separation of privileges for processes running in the same 
user's context. One goal of integrity levels is to isolate system services - especially those running in 
Session - from all other processes. 

The Integrity Mechanism adds an integrity level to security access tokens and a mandatory label for 
Access Control Entries (ACE] on the System ACL (SACL) of securable objects. There are five defined 
integrity levels: 
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Table 1 - Integrity Levels 



Value 


Integrity Level 


Symbolic Name 


0x0000 


Untrusted 


SECURITY MANDATORY UNTRUSTED RID 


0x1000 


Low Level 


SECURITY MANDATORY LOW RID 


0x2000 


Medium Level 


SECURITY MANDATORY MEDIUM RID 


0x3000 


High Level 


SECURITY MANDATORY HIGH RID 


0x4000 


System Level 


SECURITY_MANDATORY_SYSTEM_RID 



These integrity levels are used to construct integrity level SIDs (Security Identifiers) so that they 
can be easily integrated into the existing Windows access control architecture. The unique SID 
value for integrity levels is S-1-16-XXXX. So, an integrity level SID for a High Level entry would be 
S-l-16-12288 (12288 is decimal for 0x3000]. 

There are also Mandatory Access Token Policies and Mandatory Label Policies specific to Vista that 
we should discuss here. They are listed in the two tables below. 



Table 2 - Mandatory Access Token Policy 



Policy 



Description 



TOKEN_MANDATORY_NO_WRITE_UP 



TOKEN_MANDATORY_NEW_PROCESS_MIN 



Default policy on all access tokens; restricts write access 
on objects with a higher level than current token 
Controls behavior of child process integrity level 
assignment; Instead of inheriting parent level, an 
algorithm determines least possible privilege 



Table 3 - Mandatory Label Policy 



Policy 


Description 


SYSTEM MANDATORY POLICY NO WRITE UP 


Restricts write access by a subject with a lower 




integrity level 


SYSTEM MANDATORY POLICY NO READ UP 


Restricts read access by a subject with a lower 




integrity level 


SYSTEM MANDATORY POLICY NO EXECUTE UP 


Restricts execution by a subject with a lower 




integrity level 



And to see how specific user account SIDs are mapped to Integrity Levels, see Table 4 below. Notice 
how all the system accounts (LocalSystem, LocalService, NetworkService) have the highest - 
System - integrity levels, and that Administrators do not have the highest levels by default. 
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Table 4 - Account SIDs and Integrity Levels 



SID in access token 


Assigned integrity level 


LocalSystem 


System 


LocalService 


System 


NetworkService 


System 


Administrators 


High 


Cryptographic Operators 


High 


Authenticated Users 


Medium 


Everyone (World) 


Low 


Anonymous 


Untrusted 



The Integrity Levels add yet another obstacle to attackers and malicious users/code attempting to 
compromise a Vista machine. Some areas where it directly impacts a potential attacker is injecting 
code into system services and privilege escalation. Coupled with other protection mechanisms such 
as ASLR, DEP, SafeSEH it is becoming more challenging and complex to exploit and execute 
malicious code on Vista. 
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Encryption Services 

Windows Vista first offers the use of the Cryptography Next Generation (CNG] service and APIs, as 
provided by the modules BCrypt.dll, Ncrypt.dll and the kernel driver Ksecdd.sys (there are probably 
other modules involved). CNG is the successor to the CryptoAPI. CNG is well documented on MSDN 
and there is a CNG SDK available. 

Although the new CNG services were available in Vista, it wasn't until SP1 that Microsoft 
implemented some of the CNG services directly into the security components that comprise user 
logons and storage of password hashes. We will explore this area in detail in other sections of this 
paper. 
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Figure 4 - CNG Architecture 



This new CNG architecture is important to grasp as it has replaced the mechanisms used to protect 
password hashes stored in memory on Windows Vista SP1, and is the lion's share of discussion of 
this paper. 

An interesting side note about CNG and SP1: the implementation of the random number generator 
in CNG as implemented in Vista SP1 (and Windows Server 2008) is not compliant with FIPS 140-2 
RNG in several modules. 

The author will speculate that this is so because of the addition of a number of "preferred" system 
functions used for RNG creation found in SP1 that are not present in RTM. 
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SECTION II 

Protection of In Memory Password Hashes 
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A Change Is Detected 

While doing some typical security testing as part of an analysis of malicious user capabilities on a 
compromised machine - and also to validate some countermeasures that were being developed to 
clear password hashes in memory - I was using the favorite technique of dumping the various 
password stores (hashes, credentials, LSA, etc.) on Windows machines. I performed these tests 
using the usual toolsets (PWDumpX, PTH Toolkit, etc.) on both XP and Vista computers with great 
success. I later attempted this same testing on another Vista machine and discovered that the 
dumping of hashes stored in memory was not possible, even after some significant tweaking and 
digging for the necessary offsets using PTH Toolkit. I soon realized the second Vista machine was at 
SP1 and the first Vista machine was at RTM. Further analysis revealed Vista RTM behaves exactly 
the same as XP SP3 when dealing with in memory stored hashes (at least as far as my testing could 
detect). 

Disassembly and comparative binary analysis of the relevant modules and functions involved with 
the storage of in-memory hashes revealed that Vista SP1 has made some significant changes to 
these specific functions. The two functions most impacted are 

LsalnitializeProtectedMemory ( ) and LsaEncryptMemory () , both contained in 
LSASRV.dll. LSASRV.dll provides the primary services of the Local Security Authority server that is 
offered via the Local Security Authority Sub-system (LSASS.exe) user-mode process. The native 
functions of LSASRV.dll provide services for authentication, encryption, user account privileges and 
management, domain trusts and more. It is a key component of the Windows security architecture. 
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Figure 5 - eEye Darun Grim Diffing Tool on LSASRV.dll 

Using the Darun Grim diffing tool from eEye, it is obvious that there are significant differences in 
many functions contained within LSASRV.dll. By sorting on Match Rate within the tool (which 
calculates a percentage based on the differences detected between the identified functions) we see 
that LsaEncryptMemory and LsalnitializeProtectedMemory are two functions among the most 
dissimilar. 

Then, using Darun Grim's diffing-graphing capability, you can see the side-by-side differences in 
execution of the same functions in Vista and Vista SP1. 
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Figure 6 - LsalnitializeProtectedMemoryQ Comparison 



Figure 6 shows the huge difference in execution flow for LsalnitializeProtectedMemory ( ) 
between Vista and Vista SP1. Beyond the changes in raw execution flow, there are major changes in 
the functions and call structure used to generate the keys for encryption/decryption. The primary 
purpose of LsalnitializeProtectedMemory ( ) is to create the corresponding encryption 
keys for use by LsaEncryptMemory ( ) . 
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Figure 7 - LsaEncryptMemory() Comparison 



A quick look at Figure 7 shows the differences in LsaEncryptMemory ( ) do not appear as severe 
as LsalnitializeProtectedMemory () , but upon further inspection those differences 
becomes obvious. If you are not familiar with Darun Grim, the orange-brown colored boxes 
indicate pieces of code that have no match in the comparative function. The yellow boxes label 
code segments that have been modified. So you can see there is almost nothing in SP1 that exists in 
the RTM implementation of this function. 

The next section of this paper will break out the changes in LsaEncryptMemory ( ) and 
LsalnitializeProtectedMemory ( ) in greater detail via disassembly and analysis of these 
functions to determine the specific code-level modifications made and to discover any potential 
paths to malicious techniques against the new modules. 
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Detailed Analysis 

Here we will provide code level examples in C/C++ and assembly of the applicable functions 
contained with BCryptdll, and disassembly of the functions 

LsalnitializeProtectedMemory ( ) and LsaEncryptMemory ( ) . These examples will be 
broken down into three sub-sections: 

1. Relevant Functions as Defined in BCrypt.h (CNG API) 

2. Implementation examples of the relevant functions 

3. Detailed analysis of LsalnitializeProtectedMemory ( ) and LsaEncryptMemory ( ) 

Relevant Functions as Defined in BCrypt.h 

BCrypt offers many functions as part of the CNG API. It is not necessary to examine all of these 
functions - we are only concerned with the ones used in the encryption/decryption of password 
hashes in memory. The specific functions we will examine are: 

• BCryptOpenAlgorithmProvider 

• BCryptSetProperty 

• BCryptGetProperty 

• BCryptEncrypt/Decrypt 

• BCryptGenRandom 

• BCryptGenerateSymmetricKey 

Note : It is not necessary to go through all the code listings here. They are provided to give a full 
description of the functions, structures and some simple implementation examples of the functions 
we will examine from a reversing perspective. If you can follow reversing concepts and 
disassembly easily, it is not necessary to go through this section in great detail. 



Code Listing 1 - BCryptOpenAlgorithmProvider 



BCryptOpenAlgorithmProvider ( 

out BCRYPT_ALG_HANDLE *phAlgo 

in LPCWSTR pszAlgld, 

in_opt LPCWSTR pszlmplementation, 

in ULONG dwFlags) ; 



Code Listing 1 : This function returns a handle to the opened primitive algorithm specified 
by the ps zAlgid input. 
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Code Listing 2 - BCryptGetProperty 



BCryptGetProperty ( 




in 


BCRYPT HANDLE hObject, 


in 


LPCWSTR pszProperty, 


out bcount part opt (cbOutput, 


*pcbResult) PUCHAR pbOutput, 


in 


ULONG cbOutput, 


out 


ULONG *pcbResult, 


— in 


ULONG dwFlags) ; 



Code Listing 2 : This function obtains the value for the specified property of an object - such 
as the size of a key object or block cipher length. 



Code Listing 3 - BCryptSetProperty 




BCryptSetProperty ( 




inout 


BCRYPT HANDLE hObject, 


in 


LPCWSTR pszProperty, 


in bcount (cblnput) 


PUCHAR pb Input, 


in 


ULONG cblnput, 


in 


ULONG dwFlags) ; 



Code Listing 3 : This function sets the value of a specified object - such as selecting the mode 
for cipher block encryption. 



Code Listing 4 - BCryptGei 



BCryptGenerateSyitimetricKey ( 




inout 


BCRYPT ALG HANDLE hAlgorithm, 


out 


BCRYPT KEY HANDLE *phKey, 


out bcount full (cbKeyOb ject) 


PUCHAR pbKeyObject, 


in 


ULONG cbKeyOb ject, 


in bcount (cbSecret) 


PUCHAR pbSecret, 


in 


ULONG cbSecret, 


— in 


ULONG dwFlags) ; 



Code Listing 4 : This function generates the symmetric key using the specified algorithm. 
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Code Listing 5 - BCryptEncrypt 



BCryptEncrypt ( 




inout 


BCRYPT KEY HANDLE hKey, 


in bcount (cblnput) 


PUCHAR pblnput, 


in 


ULONG cblnput, 


in opt 


VOID *pPaddingInf o , 


inout bcount opt(cblV) 


PUCHAR pblV, 


in 


ULONG cblV, 


out bcount part opt (cbOutput, 


*pcbResult) PUCHAR pbOutput, 


in 


ULONG cbOutput, 


out 


ULONG *pcbResult, 


— in 


ULONG dwFlags) ; 



Code Listing 5 : This function performs the encryption . 



Code Listing 6 - BCryptGenRandom 



BCryptGenRandom ( 






inout 


BCRYPT ALG HANDLE 


hAlgorithm, 


inout_bcount_full (cbBuf fer) 


PUCHAR pbBuf f er , 
ULONG cbBuf f er , 




in 


ULONG dwFlags) ; 





Code Listing 6 : This function will fill a buffer with random bytes. 
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Implementation Examples 

The following code listings are not complete - the purpose of these listings is to show some 
implementation snippets of the relevant cryptographic functions that we will be dissecting as we 
look at how Vista encrypts some in-memory values, such as password hashes. See the Microsoft 
CNG Development Kit or Windows SDK for more details. 



Let's declare the necessary parameters we will need: 
Code Listing 7 - Declarations 



//declarations 








BCRYPT 


ALG 


HANDLE 


hAesProvider 


= 


NULL; 


BCRYPT 


KEY 


HANDLE 


hAesKey 


= 


NULL; 


NTSTATUS 




status 


= STATUS UNSUCCESSFUL; 


DWORD 






cbCipherText 


= 


0, 








cbPlainText 


= 


0, 








cbData 


= 


0, 








cbKeyObject 


= 


0, 








cbBlockLen 


= 


0, 








cbBlob 


= 


0; 


PBYTE 






pbCipherText 


= 


NULL, 








pbPlainText 


= 


NULL, 








pbKeyObject 


= 


NULL, 








pblV 


= 


NULL, 








pbBlob 


= 


NULL 








pbRandom 




NULL; 



Then open the provider that we want - in this example, it will be AES. This function returns a 
handle for the opened algorithm as hAesProvider . 
Code Listing 8 - Open Algorithm 



//open 


the 


algorithm 


handle 






if ( 


NT 


SUCCESS (status 


= BCr 


yptOpenAlgc 


rithmProvider ( 












ShAesPi 


ovider, 












BCRYPT 


AES ALGORITHM, 












NULL, 














0))) 





Once the primitive algorithm is opened you must then determine some sizes before you can do any 
work: 

• Calculate the size of the blocks for the algorithm to be used (CBC, CFB, etc.) and the key 
object itself 

• This is done via the BCryptGetProperty ( ) function: 
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Code Listing 9 - Get Size 


of Key and Block 


Length 


//calcL 


late the 


size of 


the 


buffer for the KeyObject 


if ( 


NT 


SUCCESS ( 


status = 


BCr 


yptGetProperty ( 

hAesProvider, 
BCRYPT OBJECT LENGTH, 
(PBYTE) scbKeyObject, 
sizeof (DWORD) , 
ScbData, 
0))) 


//calcL 


late the 


size of 


the 


block for IV 


if ( 


NT 


SUCCESS ( 


status = 


BCr 


yptGetProperty ( 

hAesProvider, 
BCRYPT BLOCK LENGTH, 
(PBYTE) ScbBlockLen, 
sizeof (DWORD) , 
ScbData, 
0))) 



With the proper sizes of the key object and the appropriate block lengths, some size checking and 
buffer allocation would be in order (not shown here]. 



Then you would set the proper value for the key type you need; we are using AES CBC in this 
example. After setting this value, you would then generate the key. 
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Code Listing 10 - Set Value for Key type and Generate Key 



//after some siz 
//set the value 
if (INT SUCCESS (s 



checking and buffer allocation, 

or the key to be created 

atus = BCryptSetProperty ( 

hAesProvider, 
BCRYPT_CHAINING_MODE , 
(PBYTE) BCRYPT_CHAIN_MODE_CBC, 
sizeof (BCRYPT_CHAIN_MODE_CBC) , 
0))) 



// generate the key 

if ( !NT_SUCCESS (status : 



BCryptGenerateSymmetricKey ( 
hAesProvider, 
ShAesKey, 

pbKeyObject, //key buffer 
cbKeyObject, //size of key buffe 
(PBYTE) myAESKey, //buffer with_ 
sizeof (myAESKey) , //secret key 
0))) 



The BCryptGenRandom ( ) function has many useful applications and is often used in cryptographic 
seeds, IVs and other purposes as needed. A quick example is given below: 



Code Listing 11 - Random Generator 



//Random 




fills 


a buffer with random byt 


3S 






if ( 


NT SUCCESS (stati 


is = BC 


ryptGenRandom ( 


















hAesProvider 


, 
















(PBYTE) &pbR£ 


ndom, 


//pc 


inter 


to 










sizeof (pbRar 
0) ) ) 


dom) , 


//bL 


ffer 
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Code Listing 12 - Encrypt and Decrypt functions 



// 


sav 


sa 


:opy 


of the 


key and IV for later use 




// 


*** 


Thi 


3 is 


importa 


nt because 


the BCryptEncrypt/Decrypt 




// 


fun 


=tio 


-is WJ 


11 alte 


r them so 


that they cannot be reused * 


** 


// 


We 


/fill 


not 


list th 


is code he 


re for brevity' s sake 




// 


use 


the 


key 


to encr 


ypt the pi 


aintext 




if 


!NT 


_SUCCESS 


status 


= BCryptEr 


crypt ( 
















hAesKey, //key 
















pbPlainText, //plain buff 


er 














cbPlainText, //size of bi 


ffer 














NULL, //NULL for symmetry 


c 














pblV, // buffer of IV 
















cbBlockLen, //size of IV 
















pbCipherText, //output bi 


ffer 














cbCipherText, //size of c 


utput 














&cbData, //pointer # bytes out 














BCRYPT BLOCK PADDING) ) ) 




// 


the 


dec 


rypt 


functic 


n is liste 


d as well 




if 


!NT 


^SUCCESS (status 


= BCryptDecrypt ( 
















hAesKey, 
















pbCipherText, 
















cbCipherText, 
















NULL, 
















pblV, 
















cbBlockLen, 
















pbPlainText, 
















cbPlainText, 
















ScbPlainText, 
















BCRYPT BLOCK PADDING) ) ) 





















* The BCRYPT_BLOCK_PADDING is only used with symmetric algorithms and offloads 
manual calculations of block size multiples. 
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Comparative Analysis Of LsalnitializeProtectedMemoryO and LsaEncryptMemory ( ) in 

Vista RTM and SP1 

Now that we have a solid understanding of the relevant CNG structures and functions, let's dive into 
the analysis of how they are implemented within the Vista operating system directly. 

The two functions within LSASRV.dll - LsalnitializeProtectedMemory ( ) and 
LsaEncryptMemory () - are the primary functions involved in protecting in-memory hashes of 
Windows logon sessions. LsalnitializeProtectedMemory ( ) generates the keys that will be 
used to perform the encryption and LsaEncryptMemory ( ) actually performs the encryption and 
decryption of data. 

We will be examining the significant differences in these functions between Vista SP1 and Vista 
RTM (and XP SP3 - I did not check previous versions, but suspect they will all be the same - or at 
least similar - since the "pash-the-hash" concept has applied to almost all previous NT-based OSs). 
At a high level, the protection mechanisms that encrypt in-memory password hashes have 
completely changed. Prior to Vista SP1, the primary mechanism used to perform the in-memory 
encryption was DES. Actually, it is a Microsoft specific implementation of DES called DESX (DES 
Extended]. 

In Vista SP1 (and Windows Server 2008), Microsoft has applied the new CNG functions to protect 
the in-memory hashes. The algorithms used to perform these functions are 3 DES and AES. 



In the Code Listings that will follow, please note the following : 



Vista 


RTM 


code 


will 


be 


listed 


in 


blue 


text 


boxes 




Vista 


SP1 


code 


will 


be 


listed 


in 


red 


text 


boxes 



Comments have been added throughout the code listings to make the analysis easier to follow. 



i * y 



Windows Vista Security Internals 



Code Listing 13 - Disassembly and Analysis of RTM LsalnitializeProtectedMemory 



VISTA RTM LsalnitializeProtectedMemoryQ 

ry@0 pre 



; setflProtect in VirtualAllocQ; 4 = Read/Write 



; flAllocationType; 1000 = MEM_C0MM1T - allocate memory and zero it 



mov ?g_cbRandomKey@@3KA, 

; 256 bytes for cbRandomKey 



; Call VirtualAllocQ 

mov ?CredLockedMemory@@3PAXA, . 



pus! 



pus! 



?CredLockedMemorySize@@3KA 

ds : imp VirtualLock@8 

loc_73056143 

eax, ?CredLockedMemory@@3PAXA 

?g_pDESXKey@@3PAU_desxtable@@A, . 

eax, 90h 
18h 

?g_pRandomKey@@3PAEA, eax 



s / SystemFunction036 is equivalent to 
;ADVAPI32.dll!RtlGenRandom 



: ?g_Feedback@@3_KA 



short loc_730348BF 
? g_pRandomKey @ @ 3 PAEA 
?g_pDESXKey@@3PAU_des> 



These lines are the Microsoft DES extended (DESX) algorithm that takes the random key, 
■adds /'whitening" padding from the desxtable and a Feedback value specified by g_Feedback; 

Then calls SystemFuntion036 to create the keys used for encryption - Note the use of 
;g_pDESXKey, g_Feedback 



:mory@0 endp 
5— 



Windows Vista Security Internals 



Code Listing 14 - Disassembly and Analysis of SP1 LsalnitializeProtectedMemory 



VISTA SP1 LsalnitializeProtectedMemorvQ 



; "Store string" instruction - puts contents ofEAXinto address at EDI 
; this is done four times (only showing one here) 



stosw ; "Store string" instruction for AX 

push offset a3des ; "3DES" 
push offset ?h3DesProvider@@3PAXA 

s t o s b ; "Store string " instruction for AL 

mov [ebp+var_24], ebx 

mov [ebp+var_28], ebx 

mov [ebp+var_20], ebx 

call _BCrypt0penAlgorithmProvider@16 

; First instance of call to new CNG Dll - Bcrypt.dlUBcryptOpenAlgorithmProvider 
; Here the 3DES algorithm provider has been opened 



offset ?hAesProvider@@3PAXA 
_BCryptOpenAlgorithmProvider{ 



; Open the AES algorithm provider 



; Set the 3DES provider to use the BCRYPT_CHAIN_MODE_CBC mode for symmetric keys 



; Set the AES provider to use the BCRYPT_CHAIN_MODE_CFB mode for symmetric keys 



x, [ebp+var_20] 

--= CONTINUED = 
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offset aObjectlength 
?h3DesProvider@@3PAXA 
[ebp+var_20] , edi 
_BCryptGetProperty@24 



; BCryptGetProperty - get the size of the key object for 3DES 



loc_71AF59FB 
[ebp+var_20], 

loc_71AF59E6 



offset aObjectlength 
?hAesProvider@@3PAXA 
[ebp+var_20], edi 
_BCryptGetProperty@24 



; BCryptGetProperty - get the size of the key object for AES 



txt 


cmp 


esi, eax 




jl 


loc 71AF59FB 


text 


cmp 


[ebp+var 20] 


text 


jnz 


loc 71AF59E6 


text 


mov 


eax, [ebp+va 
ecx, [ebp+va 



loc_71B14AC8 

edi, ?CredLockedMemory@@3PAXA 

eax, [ebp+var_24] 



mov [ebp+var_2C], eax 

push 18h 

lea eax, [ebp+var_lC] 

push eax 

push ebx 

call _BCryptGenRandom@16 

; BCryptGenRandom -fill a buffer with random bytes 



lea eax, [ebp+var_lC] 

push eax 

push [ebp+var_24] 

push edi 

push offset ?h3DesKey@@3PAXA 

push ?h3DesProvider@@3PAXA 

call _BCryptGenerateSymmetricKey@2 8 

; Generate the Symmetric Key with 3DES 
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eax, [ebp+var_lC] 
_BCryptGenRandom@li 



lea eax, [ebp+var_lC] 

push eax 

push [ebp+var_28] 

push [ebp+var_2C] 

push offset ?hAesKey@@3PAXA 

push ?hAesProvider@@3PAXA 

call _BCryptGenerateSymmetricKey@2 8 

; Generate the Symmetric Key with AES 



; reference the IV 

push ebx 

call _BCryptGenRandom@l< 
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Code Listing 15 - Disassembly and Analysis of RTM LsaEncryptMemory 



Vista RTM LsaEncryptMemory 

?LsaEncryptMemory@@YGXPAEKH@Z proc ne; 



= dword ptr -HOh 
= dword ptr -lOCh 
= byte ptr -108h 
= dword ptr -4 

= dword ptr OCh 



edi, edi 
ebp 



mov ebp, esp 

sub esp, HOh 

mov eax, security_cookie 

mov [ebp+var_4], eax 

push esi 

mov esi, [ebp+arg_0] 

jz short loc_730180B0 

push ebx 

mov ebx, [ebp+arg_4] 

jz short loc_730180AF 

jnz loc_730560F7 

mov eax, ?g_Feedback@@3_KA 

; unsigned _int64 from LsalnitializeProtectedMemory 



[ebp+va] 
[ebp+va: 



1_731171EC 



:_730180AF 
eax, [ebp+var_110] 
[ebp+arg_8] 

?g_pDEsxKey@@3PAu_desxtabie@@A / DES table; key plus whitening 



offset desx@i6 ; DESX function 
cbc@ 2 8 ; Cipher block chain mode - performs the encryption 



?LsaEncryptMemory@@YGXPAEKH@Z endp 
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Code Listing 16 - Disassembly and Analysis of SP1 LsaEncryptMemory 



Vista SP1 LsaEncryptMemory 

?LsaEncryptMemory@@YGXPAEKH@Z pre 



= byte ptr - 


14h 


; ptr for IV 


= dword ptr 


-4 




= dword ptr 


8 


; uchar * 


= dword ptr 


OCh 


; ulong 


= dword ptr 


lOh 


; int -Oorl 



[ebp+var_4], eax 
eax, [ebp+arg_0] 
ecx, ?h3DesKey@@3PAXA 



[ebp+var_lC] , edx 
short loc_71AD9D0B 

[ebp+arg_4], edx 
short loc_71AD9D0B 
byte ptr [ebp+arg_4], 7 



; mask ulong arg_4 with 00000111 



esi, offset ?InitializationVector@@3PAEA 
edi, [ebp+var_14] 

; movsd = mov dword from ESI to EDI - here the IV is being moved into 
;the pointer specified by var_14. Four movsd means 128 bits 



1B14AB6 ; If not zero after 128 bits, Go to AES stuff 



si, [ebp+arg_8] 



esi, edx 

short loc 71AD9D2F 


; Encrypt or Decrypt'. 
; = Decrypt 


short loc 71AD9D09 

edx 

esi, [ebp+var_lC] 




[ebp+arg 4] 

esi, [ebp+var_14] 

[ebp+var_18] 




[ebp+arg_4] 




ecx 




BCryptEncrypt@4 


; Encrypt data 




= CONTINUED =-- 
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loc_71AD9D05 



:_71AD9D0B: 

>v ecx, [ebp+i 



?LsaEncryptMemory@@YGXPAEKH@Z endp 

;Jump location for theAES key 



loc_71B14AB6: 

mov ecx, ?hAesKey@@3PAXA 
mov [ebp+var_18] , lOh 
jmp loc 71AD9CE4 



;Jump location for the Decrypt function 

loc_71AD9D2F: 
push edx 
lea esi, [ebp+var_lC] 



; Decrypt data 
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Observations of Analysis 

It is obvious that Microsoft has significantly changed the implementation of algorithms to protect 
password hashes stored in memory. The DESX algorithm is no longer used for this purpose as of 
Vista SP1 and Windows Server 2008. Other changes are listed below: 

Most of the encryption process is self-contained in pre-SPl code (LSASRV.dll); in SP1, 

LSASRV.dll makes external calls to BCrypt.dll to provide these functions 

There are no SystemFunctionXXX ( ) calls in SP1 encryption/decryption of in-memory 

password hashes 

The CNG API provides all cryptographic functions for password hashes stored in memory in 

SP1 



The new CNG API is implemented by BCrypt.dll primarily, with storage support provided by 
NCryptdll and kernel support implemented in Ksecdd.sys. The algorithms that provide protection 
of in memory password hashes in Vista SP1 3are DES and AES. 



Although the algorithms have changed, the existing tools of the trade that could extract in memory 
password hashes attacked the keys or used DLL injection - can we do the same in Vista SP1? Is the 
implementation of the algorithms similar enough so that the same basic techniques can be applied 
to obtain the in memory hashes? DLL injection - particularly with LSASS - can be problematic due 
to the concept of Integrity Levels in Vista for system services. ASLR may also make this difficult. 
Another technique was to find the encryption key in memory and use that to just read the hashes 
right out of memory. 



The corresponding presentation to this paper will demonstrate the possibility of obtaining the in- 
memory hashes by utilizing similar techniques as existing toolsets. 



Challenges to Extracting the Hashes 

Some of the challenges already identified to obtaining the password hashes stored in-memory on 
Vista SP1 are listed here: 

- Different base address of LSASRV.dll on each boot (ASLR) 

Integrity Mechanism/Levels make DLL injection more difficult 

Different algorithms used for encryption/decryption - i.e. - cannot swap code and offsets 

from other tools 

Current research indicates the key and IV used during encryption of the hashes in memory 

are not available after the encrypt/decrypt function, or they are modified in a way that 

prevents direct re-use. This research is still on-going, however. 

This author does not believe these challenges to be permanent and is looking for solutions to 
address these challenges. By sharing this information with the InfoSec community, perhaps others 
can discover solutions to these items, because it can be assumed that the malicious community has 
done/will do so soon. 
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